Data General and Omron in association with the X Consortium have designed and implemented a multi-threaded version of the X server called MTX [18]. The project has two major goals:
Figure 2: MTX server threads organization. Circles represent
threads; squares represent I/O sources; parallel lines
represent monitors.
MTX allows X requests from multiple connections to be dispatched concurrently. On a multi-processor machine, overall throughput could be increased. The server overhead of multiplexing multiple connections is reduced because two threads are dedicated to each client connection; all client I/O does not have to be dispatched by a single thread using select.
But MTX does have disadvantages. It uses relatively fine-grain locking (particularly compared to the locking required for multi-rendering) on nearly all X server data structures. While minimizing the costs of locking and synchronization was a primary performance concern, locks add overhead to all operations requiring locking. Compare this with no locks needed for a single-threaded X server.
The most recent publicly available performance characterization of an
MTX server indicates 75% of the tested x11perf tests were within
plus or minus 10% of a comparable X11R5 single-threaded
server.
It should be noted that
x11perf involves only a single client so no lock conflicts were
likely to be encountered. In real use, lock conflicts would add extra
overhead which is hard to characterize based on x11perf results. It is
claimed that ``in general, clients do not seem to generate many
resource conflicts,'' though window
managers do tend to create conflicts. A subjective characterization of
the performance indicates that using MTX, interactivity is
improved compared to a single-threaded server.
MTX does introduce substantial changes to the general organization of the X server. Locking and other concurrency issues diverge the MTX server source code from the X Consortium's current single-threaded sample implementation and complicate X server maintenance. The design specification for MTX [8] is comprehensive and does include guidelines for writing extensions; but code added to the MTX server must be re-entrant, thread-safe, and abide by MTX locking rules. The burden for X server maintenance complexity should be included in the appraisal of the MTX approach.